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CONSUMER RATING AND BEHAVIORAL EVALUATION SYSTEM 

RELATED APPLICATIONS 
5 U.S. Patent Applications No. 09/630,053 (Atty Docket 

No. M-8180 US) entitled " Broadcast Program Capture and 
Playback Enhancement Signal Structure, Receiver, and Method" 
by Edward J. Costello, Albert W. Wegener, Thomas M. Linden, 
and Serge Swerdlow, and 09/63 0,037 (Atty Docket No. M-8182 
10 US) entitled "Quality of Service Method and Apparatus for 
Received Programs'' by Albert W. Wegener, Orlando Martinez, 
Edward J. Costello, Jonathan Voichick, Eric X. Wen, and 
Thomas M. Linden, filed concurrently with this application, 
are incorporated herein by reference. 

15 

BACKGROUND 

1. Field of invention. 

The present invention relates to information delivery 
services, and in particular to transmitting information from 
20 receivers in a local storage and playback broadcast system 
back to the broadcast program service provider, wherein the 
information transmitted back includes data regarding 
broadcast program reception quality and user behavior. 

2 5 2. Related art. 

In many audio playback systems the selected audio, 
programs are delivered on a physical medium, such as compact 
disk (CD), analog tape (e.g., cassette), or removable 
semiconductor memory (e.g., SmartMedia® card manufactured by 

30 Toshiba Corporation, Memory Stick® by Sony Corporation, or 
CompactFlash® by Sandisk Corporation) . The likelihood of 
successful program playback is high as long as the storage 
medium is undamaged. Alternatively, in certain types of 
information delivery systems audio programs are broadcast 
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for live playback using media such as commercial amplitude 
and frequency modulated (AM, FM) radio or television 
signals. The likelihood of high quality playback using 
broadcast signals is proportional to the quality of signal 
5 reception. The larger the distance between transmitter and 
receiver, for example, the lower the likelihood of 
acceptable playback quality. For instance, in a typical 
commercial radio live (direct) broadcast system, users 
(listeners) are likely to tune to another broadcast station 

10 when subjective playback quality becomes unacceptable. 

Another communications system alternative is to 
broadcast audio programs to a mobile receiver for local 
storage (e.g., in the receiver) and subsequent playback. In 
such local storage and playback broadcast systems, it is 

15 desirable for the service provider to monitor the quality of 
broadcast programs as they are received, stored, and played 
back to users. It is well-known in the 

entertainment/information fields for the service provider to 
monitor the users' behavior. Technical difficulties have 
20 until now generally prevented such monitoring with mobile 
receivers, however, although the capability is desirable. 

SUMMARY 

In a local storage and playback wireless broadcast 
25 system, a "back channel" is provided that supplies 

information to the service provider. The information is 
associated with signal and program quality reception at the 
receiver, and also the receiver user's program content 
consumption and receiver use patterns. The receiver records 
3 0 and stores in memory selected "back channel events." The 
service provider distributes a removable storage medium to 
the user who inserts the medium into a recording unit in the 
receiver, downloads the stored events onto the storage 
medium, and returns the storage medium to the service 
3 5 provider. 
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Back channel events include capture events, storage 
events, playback events, control events, and quality events. 
Capture events are associated with the receiver's capture 
and reassembly of broadcast program content. Storage events 
5 are associated with the management of programs stored in the 
receiver's memory. Playback events are associated with the 
user's actions regarding playback of the stored programs. 
Control events include information regarding the receiver's 
reception frequency tuning actions and changes in receiver 
10 power source . Quality events are associated with the 
quality of the program content as received. 



BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a representation of a communication system. 
15 FIG. 2 is a block representation of a receiver. 

FIG. 3 is an illustration of the time sequence of 
program transmissions. 

FIG. 4 illustrates an audio program structure composed 
of segments, packets, and blocks. 
20 FIG. 5 is an illustration of the data structure for a 

signal portion transmitted to the receiver. 

FIG. 6 is a memory map. 

FIG. 7 is a flow diagram showing an embodiment of 
packet quality evaluation. 
25 FIG. 8 illustrates a segment reassembly process. 

FIG. 9 is an illustration of an embodiment of received 
program reassembly and evaluation based on quality of 
service parameters. 

FIG. 10, composed of FIGs . 10A and 10B, is a flow 
30 diagram illustrating a quality of service evaluation 
embodiment . 

FIG. 11 is a flow diagram illustrating a second 
embodiment of a quality of service evaluation. 

FIG. 12 is a flow diagram of a segment evaluation 
35 embodiment. 
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FIG. 13 is a diagram illustrating the use of a 
removable storage medium for back channel operation. 

FIG. 14 is a diagram illustrating an embodiment of a 
card reader. 

5 

DETAILED DESCRIPTION 

Identical element numbers shown in the figures 
represent the same or similar features. Portions of the 
system are not shown so as to more clearly describe the 

10 present invention. 

Embodiments are directed to an audio/video-on-demand 
broadcast system that delivers a user's (system 
subscriber's) preselected audio/video programs ("content") 
and system administrative features ("software," 

15 "parameters") to the user. Examples of an audio-on-demand 
system are provided in the patent application and patents 
referenced below. In addition, other broadcast 
communications systems fall within the scope of the 
disclosed embodiments. Persons skilled in communications 

20 will understand that other "programs" (video, text, 
graphics, etc. originating from commercial radio, 
television, or other sources and communication channels) are 
included in the embodiments described herein. U.S. Patent 
Application Serial No. 09/454,901, filed 3 December 1999 and 

25 entitled "Wireless Software and Configuration Parameter 

Modification for Mobile Electronic Devices" is incorporated 
herein by reference. U.S. Patents No. 5,406,626; 5,524,05; 
5,590,195; 5,751,806; 5,809,472; and 5,815,671 are also 
incorporated herein by reference. 

30 FIG. 1 is a representation of a wireless (radio) 

communication system. As shown, service center (head end) 
102 includes database 104 (maintained on a conventional 
computer, not shown) and transmitter 106. Information 
stored in database 104 includes entertainment programs 

35 (e.g., news, sports, music), data (e.g., stock market data), 
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software upgrades for the receiver, and system operating 
parameters (e.g., activation/deactivation codes, a program 
guide for the user, quality of service parameters) . 
Information in database 104 is conventionally digitally 
5 encoded and is directed to, for example, transmitter 106 for 
transmission in signal 108. Specifics regarding the data 
structure used to transmit the programs in fixed length data 
units (packets) are disclosed below. 

As depicted, in one embodiment radio signal 108 is 

10 relayed through satellite 110 to local receiver/transmitter 
112 to allow wide geographic coverage. In some embodiments, 
however, the signal is transmitted from service center 102 
directly to receiver/transmitter 112 (e.g., using 
conventional radio or television signals, land line, or 

15 optical fiber) . Receiver/transmitter 112 relays the 

information as signal 114 to each individual user's mobile 
receiver 116. The transmission between receiver/transmitter 
112 and receiver 116 is by amplitude modulated (AM) or 
frequency modulated (FM) radio, FM sideband radio, or other 

20 broadcast method. For example, in some embodiments signal 
114 is transmitted as a data signal on an FM subcarrier 
within one or more frequency ranges in unused portions of 
the commercial FM broadcast spectrum (88.0 - 108.0 megahertz 
(MHz) ) . In other embodiments service center 102 transmits 

25 directly to receiver 116. 

Receiver 116 is typically a mobile (portable) unit and 
includes a conventional visual display 120 (e.g., liquid 
crystal (LCD) or thin-film transistor (TFT) ) , conventional 
keypad 122, and conventional output audio transducer 124 

30 (e.g., an audio speaker or headphone). Display 120 presents 
information or descriptions of selected programs to the 
user. Transducer 124 outputs programs and other information 
to the user as audio (playback) . The user makes program 
selections by pressing keys on keypad 122. In the 

35 illustrative audio -on -demand system, for example, a menu of 
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available programs (program guide) is displayed to the user 
on display 120 and the user selects programs for output 
using keypad 122. The selected programs are captured from 
signal 114, stored in the receiver, and are output using 
5 transducer 124 at the user's discretion. The receiver may 
be a hand-held portable device, or may be incorporated into 
a larger system such as an automobile radio, 

FIG. 2 is a block representation of several 
interconnected components of receiver 116. Electrically 

10 conductive interconnections between components are described 
as a M line" in the description that follows, although 
persons skilled in the art will understand that the 
interconnections may have one or more physical coupling 
paths. Some interconnections, such as those to the power 

15 supply system, and other components are omitted to more 
clearly show the features of several embodiments. The 
components and their configuration are illustrative and many 
acceptable variations exist. 

Logic unit 202 functions as a central processing unit 

20 (CPU) and includes a conventional 

microprocessor/microcontroller (e.g., Motorola MC68307) . 
Logic unit 202 is electrically coupled via line 203 to 
conventional NOR flash memory 204 (e.g., AM29LV4 00BB-120E 
manufactured by Advanced Micro Devices, Inc.), conventional 

25 random access memory 206, and conventional NAND flash memory 
208 (e.g., TH58V128FT manufactured by Toshiba, Inc.). 
Memories 204, 206, and 208 together comprise content storage 
memory 210. In one embodiment memory 210 has sufficient 
capacity to store approximately eight hours (for normal 

30 playback) of received compressed audio programs. 

Details regarding the memory and information storage 
are described in U.S. Patent Application 09/454,901, cited 
above. Quality of service parameters discussed below may be 
considered options as described in that application. In 

35 some embodiments the quality of service parameters are 
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included in the broadcast program guide that is used to 
present the menu of available programs to the user. Quality 
of service parameters may be varied for each program. 
Therefore in some embodiments each program's quality of 
5 service parameters are broadcast within the same data 

structure that describes the program's name and availability 
(program guide) . Quality of service parameters can also be 
separately broadcast from the program guide. 

Logic unit 202 is electrically coupled via line 211 to 

10 conventional digital signal processor (DSP) 212 (e.g., Texas 
Instruments TMS 320 C52) . In some embodiments DSP 212 
contains conventional Viterbi and Reed-Solomon error 
correction decoders. Conventional DSP memory 214 is also 
electrically coupled via line 215 to DSP 212. 

15 Logic unit 202 is coupled via line 217 to receiver unit 

218. DSP 212 is coupled via line 219 to receiver unit 218, 
and antenna 220 is coupled to input terminal 221 of the 
receiver unit. In one embodiment receiver unit 218 is a 
conventional tunable frequency modulated (FM) receiver 

20 capable of tuning to and receiving information from a signal 
broadcast as an FM subcarrier in the commercial FM frequency 
band. Tuning is controlled by logic unit 202 that accesses 
a list stored in memory of FM frequencies, described below. 
Signals, such as signal 114, received by receiver unit 218 

25 are directed to DSP 212 for decoding and further processing 
as described below. Logic unit 202 acts together with 
receiver unit 218, DSP 212, the associated memories, and 
other components to capture, reassemble, decode, use, store, 
evaluate, delete from storage, and output as described below 

30 the program information from the broadcast signal. 

Conventional visual display unit 222 is electrically 
coupled via line 223 to logic unit 202. Display unit 222 
functions to output visual information (e.g., program guide, 
play time remaining) to the user, and includes display 12 0 

3 5 as shown in FIG. 1. 
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User input unit 224 is coupled to logic unit 202 via 
line 225 to logic unit 202. Input (user interface) unit 224 
includes, for example, keypad 122 (FIG. 1) and may also 
include switches or other conventional mechanisms for 
5 receiving user input . In some embodiments input unit 224 
includes a conventional speech recognition system that 
allows the user to direct spoken commands to logic unit 202. 
Users activate one or more switches or buttons to play back 
stored audio programs, thus accessing stored content at 

10 their convenience. 

Output unit 226 is coupled via line 227 to digital 
signal processor 212. Output unit 226 includes a 
conventional audio output speaker, and in some embodiments a 
headphone output terminal, for outputting audio (e.g., 

15 speech, music) programs to the user. In some embodiments 
the output unit includes a conventional speech synthesizer 
for outputting human speech. 

Power system 228 is coupled to logic unit 202 via line 
229. Power system 228 provides power to the various 

20 receiver components from power source 230. Power system 228 
is conventionally adapted to receive electric power from 
several direct current (DC) power sources such as a battery 
pack, a conventional alternating current (AC) adapter 
plugged into a wall socket, or an automobile cigarette 

25 lighter socket that receives power from either the 

automobile's battery or regulated DC from the alternator. 
Power system 228 distinguishes these power sources by 
monitoring the input voltage from power source 230. In one 
embodiment a voltage below 6.2 V is presumed to indicate a 

3 0 battery pack, voltage between 6.2 V and 11.8 V to indicate 
an AC adapter, between 11.8 V and 12.5 V to indicate an 
automobile cigarette lighter with the engine off, and above 
12.5 V to indicate an automobile cigarette lighter with the 
engine running. 
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Recording unit 232 is coupled via line 233 to logic 
unit 202 and allows data from the memories to be copied to 
and recorded on removable data storage medium 234 that is 
removable from the recording unit, as illustrated by the 
5 dashed lines. This removable storage medium is referred to 
as a "back channel card" below. In one embodiment medium 
234 is a SMARTMEDIA® card manufactured by Toshiba, Inc. 
Other embodiments may use other removable storage media such 
as CompactFlash® memory, multimedia cards, or secure digital 

10 (SD) cards. In some embodiments output terminal 235 is 
placed on line 23 3 to allow direct output of data rather 
than by recording on medium 234 . 

In the illustrative system, each separate portion of 
information (content, software, parameters) is termed a 

15 "program" and is assigned a unique program identifier (e.g., 
number) at service center 102. Some programs are 
transmitted once during a particular time interval. Other 
programs are transmitted several times. Thus FIG. 3 is an 
illustration of the time sequence of program transmissions. 

20 All program identifiers (e.g., program number 3) are 

illustrative and can be modified from time-to-time by the 
audio-on-demand service provider. For instance, activation 
information 3 02 is assigned program number 3 and is 
transmitted twice. The receiver software upgrade 3 04 is 

25 assigned program number 17 and is transmitted three times. 

Audio feature program 3 06 is assigned program number 3 85 and 
is transmitted once. In practice the number of 
transmissions per program varies, and the programs are 
interleaved for broadcast . 

30 The receiver identifies the program by using the 

assigned program identifier. The receiver compares the 
program identifier in the signal to identifiers in a capture 
list stored in the memory. The capture list contains the 
identifiers for the programs that the user wants to hear, as 

35 well as identifiers for programs used for receiver 
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administration (e.g., software updates). The desired 
programs are then captured, stored, and made available for 
playback, usually in the same order each day. The capture 
list may be modified by users (customers) using keypad 122 
5 (FIG. 1) on user input unit 224 (FIG. 2) . During playback 
of one program, the user may skip to the next program in 
sequence by pressing a "next" button on input unit 224. 
Programs are normally deleted from memory after playback, 
but the user may choose to store a particular program in a 

10 designated " stored programs" area of memory 208 by pressing 
a "store" button. When the "store" button is pushed, the 
logic unit copies the program from the playback area to the 
stored programs area of the memory. 

Each program is broadcast in a program signal (e.g., 

15 108, 114 in FIGs. 1 and 2) . The digitized program is 
divided into fixed length data units ("packets") which 
themselves are composed of blocks of compressed data. The 
packets within each program are grouped into at least one 
program "segment." FIG. 4 illustrates an audio program 

20 structure composed of segments, packets, and blocks. This 
illustrative program is approximately eight minutes and 
fifty-eight seconds (8:58) in duration. As shown, program 
400 is composed of seven segments Si-S 7 , each segment being a 
different length and so made up of different numbers of 

25 packets. Each segment S1-S7 includes both a segment header 
and segment data. For example, segment S x includes segment 
header 401a and segment data 401b. Similarly, segments S 2 -S 7 
include segment headers 4 02a-407a and segment data 402b- 
407b # respectively. Each segment header 401a-407a includes 

30 information, described in detail below, associated with the 
particular segment. Each segment data 401b-407b includes 
the segment content that is, for example, decompressed and 
then output to the user as audio . 

Each segment within a program represents a particular 

35 logically coherent portion, such as a news story, song, or 

-10- 
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other comprehensive information grouping. If the program is 
a news program, for example, each segment is a separate news 
story. Alternatively, if the program is a traffic report, 
each segment covers traffic conditions in a particular area. 
5 In some embodiments the user may skip over undesired 
segments during program playback by pressing a "scan 
forward" button on his or her receiver keypad. Programs and 
segments may also contain software data or parameters for 
the receiver's internal use. 

10 Segment S 3 is shown expanded to illustrate that it is 

composed of forty-two packets P!-P 42 . Each packet P3.-P42 is 
made of 144 6 -Byte compressed data blocks so that each 
packet is 864 Bytes long. Packet P 5 is shown expanded to 
illustrate that P 5 is composed of blocks B1-B3.44. The segment 

15 S 3 segment header 403a includes, for example, packets P1-P3. 
The remaining packets P4-P42 are associated with the segment 
S 3 segment data 403b. The other segments Si, S 2 , and S 4 -S 7 
are composed of similar packets. 

For this example the programs are compressed before 

20 broadcast (e.g., using the AMBE® code, developed by Digital 
Voice Systems, Inc.) and decompressed by the receiver before 
output to provide an effective playback rate of 300 Bytes 
per second (B/sec) . There are 6 Bytes per compressed data 
block, and 50 compressed data blocks per second are 

25 transmitted. During playback the audio is decompressed to a 
rate of 16 kB/sec (16 -bit samples played at a rate of 8000 
samples/sec) . This decompression represents an 
approximately 53 -fold expansion and shows that the use of 
compressed speech and audio increases the number of programs 

3 0 that can be offered on the broadcast signal to the user. In 
some embodiments the broadcast data transmission rate is 
between 2 and 4 times the program playback rate, although 
the transmission and playback rates are independent. 
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Each data block when decompressed yields approximately 
20 milliseconds (msec) of audio program. Accordingly, each 
packet yields approximately 2.88 seconds (sec) of playable 
audio (864 Bytes/Packet * Block/6 Bytes * 20 msec/Block) . 
5 Since segment S 3 has 42 packets, the duration of S 3 is 

approximately two minutes (120.96 sec). For program 402, 
composed, of segments Si-S 7 , the segment durations are as 
shown in TABLE I for a total duration of 538 seconds (8:58). 
In many situations, however, the length of the segment data 
10 will not correspond to an exact multiple of the packet 

output duration, and so the last portion of the final packet 
in a segment (e.g., packet P42) will not contain useful 
information . 

15 TABLE I 



Segment 


No. Packets 


Duration 
(approx. ) 


1 


42 


121 sec. 


2 


11 


32 sec. 


3 


42 


121 sec. 


4 


16 


46 sec. 


. 5 


63 


181 sec. 


6 


6 


17 sec. [ 


7 


7 


20 sec. 



FIG. 5 is an illustration of the data structure for the 
signal broadcast to the receiver. In some embodiments, the 
broadcast signal uses coding typical to many wireless 
20 systems and includes a convolut ional inner code (e.g., based 
on the Viterbi algorithm) , two interleavers , a Reed- Solomon 
outer code, and synchronization words (sync words) that aid 
initial signal acquisition. The error- correcting codes and 
sync words provide the receiver with the capability to 
25 detect and correct signal data transmission errors. 

Program-related information is grouped into a 
w superframe" 502 that includes four packets 504 , 506, 508, 
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and 510 and a combined 112 -Byte header 512 that includes a 
table of contents. One superframe embodiment contains 3568 
data Bytes (112 + (4 * 864)). In one embodiment each 
superframe is broadcast at a rate of about 102 5 
5 Bytes /second, and so the time required for each superframe 
transmission is approximately 3.48 sec. In one embodiment, 
one unique sync word is placed at the start of each 
superframe, and fourteen additional sync words are equally 
spaced within the superframe. 

10 Superframe header 512 includes several administrative 

fields 512a that contain information required to manage the 
program delivery service. These fields include information 
such as the market code, the list of FM frequencies that 
carry the program signal, and the current date and time. 

15 The market code identifies the geographic region (market) in 
which the receiver is located. The list of FM frequencies 
identifies one or more frequencies in which the same audio - 
on-demand data is broadcast. When the receiver fails to 
reliably receive a broadcast signal on one frequency, the 

20 receiver references the list of FM frequencies to identify 
the next frequency to which the receiver should tune to 
reaquire a data signal. The date and time information 
synchronizes the receiver clock (not shown) with the 
broadcast system time. 

25 Superframe header 512 also includes a table of contents 

512b associated with the packets that follow in the 
superframe. Information about the parameters included in 
the table of contents is described in detail below. 

As shown, each of the four packets in the superframe 

30 originate from four unique programs 520, 522, 524, and 526. 
Thus if the superframe cannot be recovered without error 
(e.g., transmission anomaly causes superframe damage) the 
burden of unusable or missing packets is shared among more 
than one program. Alternatively, the superframe may contain 

35 packets from fewer than four unique programs. 
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In one embodiment the superframe is divided into 16 
conventional Reed-Solomon error correction blocks 530. Each 
Reed-Solomon block contains 223 data Bytes (for the 
superframe, 16 * 223 = 3568), to which the Reed-Solomon 
5 coding adds 32 error correction bytes (total of 255 Bytes 
per Reed-Solomon block yielding a superframe size of 4080 
Bytes prior to convolutional coding and insertion of sync 
words) . Thus each packet includes portions of 4 or 5 Reed- 
Solomon blocks. The 32 error correction bytes allow DSP 

10 212, which contains the Reed- Solomon decoder, to correct up 
to 16 Byte errors within the 255 -Byte Reed-Solomon block. 
In addition, the Reed-Solomon decoder can detect when more 
than 16 Byte errors have occurred within one Reed-Solomon 
block, and so can detect a failure of the error-correction 

15 system. 

Processing Parameters 

During operation, the audio/video-on-demand receiver 
should accomplish three general tasks to ultimately output 

20 received programs to the user. First, the receiver should 
process received packets in order to reassemble the 
broadcast program. Second, when the receiver determines 
that it is capturing a new program, it should allocate 
memory for the captured program's storage. Third, the 

25 receiver should have information available that controls 
segment output to the user. Thus program reassembly and 
storage, along with segment playback, are key receiver 
tasks, and several parameters are provided to assist these 
tasks. Logic unit 202 uses these software parameters during 

3 0 receiver operation. 

Certain program- specif ic (unique to each program) , 
segment-specific (unique to each segment) , and packet- 
specific (unique to each packet) parameters are used. Some 
of these parameters are required and others are optional. 
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Program-specific parameters include the program 
identifier, the number of segments per program, the number 
of Bytes per program, the program edition time, the earliest 
program play time, the program expiration time, the number 
5 of repeat transmissions, and the transmission repetition 
number . 

The program identifier, as described above, identifies 
the specific program being broadcast. 

The number of segments per program allows the receiver 
10 to anticipate memory space required to store the program, 
and in particular the size of the required offset index 
described below. 

Similarly, the number of bytes per program (program 
size) allows the receiver to allocate sufficient memory for 
15 program storage, or to determine that insufficient free 
memory exists . 

The program edition time parameter is a value that 
uniquely identifies the particular program edition, such as 
a particular news program that is periodically updated 
2 0 throughout the day. For embodiments that broadcast two or 
more editions of a program with the same program identifier, 
the receiver uses the edition time parameter to determine if 
a stored version (earlier edition) of the program should be 
replaced with a currently received version (subsequent 
25 edition) . 

The earliest program play time parameter identifies the 
earliest allowable playback time. For instance, a 
particular audio program may be contractually limited from 
playback using the audio -on -demand system until the program 
30 is first locally broadcast on a commercial "live" broadcast 
system. 

The program expiration time parameter sets a time after 
which the stored program is unavailable for playback. For 
instance, the expiration time parameter identifies a time at 
35 which the program is no longer expected to be useful, or 
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implements a contractual obligation under which the program 
may not be stored in excess of a particular duration (e.g., 
30 days) . 

The number of repeat transmissions is the total number 
5 of repeat transmissions for this particular program. The 
transmission repetition number identifies the position of 
the particular program transmission in the series of total 
program transmissions. That is, for a program that is 
transmitted three times, the repetition number is either 1, 
10 2, or 3, and the total transmissions is 3. The receiver can 
therefore anticipate the total number of transmissions for a 
particular program. 

The total repeat transmissions and repetition number 
information allows the receiver to determine, for example, 
15 that if a particular program has not satisfied a quality of 
service threshold, as described below, after the last repeat 
transmission the receiver can free memory holding the stored 
substandard program for a new program capture. 

Segment -specific parameters include the segment number, 
2 0 the packets per segment, the Bytes per segment, the segment 
content type, and the remaining play time. 

The segment number parameter identifies the segment 
sequence in the program. 

The packets per segment parameter allows the receiver 
25 to allocate sufficient memory space for the segment. 

The Bytes per segment parameter allows the receiver to 
stop segment playback at a particular location (e.g., 
completion of the usable content portion of the segment) 
since, as noted above, the last packet in the segment may 
30 not be completely filled with compressed blocks. 

The segment content type parameter identifies the 
compression method used for the particular segment. Some 
programs, for instance, may include both speech and music 
content, each compressed using a different method. 
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The remaining play time parameter is a value 
identifying the remaining program playback duration. In a 
program containing three one -minute playback duration 
segments, for example, the remaining play time parameters 
5 for segments 1, 2, and 3 are 3:00, 2:00, and 1:00, 

respectively. In some embodiments the remaining play time 
parameter represents the starting value of a count -down 
clock that is displayed to the user on the receiver's visual 
display (e.g., 120, FIG. 1). The remaining play time 
10 parameter is adjusted/derived to account for missing 
segments . 

In some embodiments the number of Bytes per segment 

parameter is derived from the number of Bytes per packet 

parameter for a given segment. And in some embodiments, the 
15 remaining play time parameter is derived from the segment 

size and content type parameters. 

In addition to program- and segment -specif ic 

parameters, other parameters are associated with packets. 

One packet-specific parameter identifies the packet's 
2 0 sequence number within a given segment. Another packet - 

specific parameter identifies the number of Bytes per 

packet . 

The program, segment, and packet parameters listed 
above may be classified into two logical groups. One group 

25 is related to program reassembly and need not be stored 

along with the program for playback. Reassembly parameters 
should, however, be quickly available to the receiver to 
allow proper program capture. This program reassembly group 
includes the program identifier, the segment number, the 

30 packet sequence number, and the packets per segment. 
Parameters in the second group are stored with the 
reassembled program and are related to program storage 
and/or playback. This storage and playback group includes 
edition time, segments per program, Bytes per program, 

35 earliest play time, expiration time, content type, Bytes per 
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segment, remaining play time, and Bytes per packet. As 
discussed below, the parameters may be broadcast to the 
receiver as part of the superframe header or the segment 
header . 

5 Some parameters are required for proper receiver 

operation. For example, each transmitted packet is 
identified by four unique elements: the program number to 
which the packet belongs, the segment number to which the 
packet belongs, the packet sequence number within the 
10 segment, and the program edition time (if applicable) . Thus 
in some embodiments the receiver must receive these 
parameters . 

In some program broadcast circumstances, however, one 
or more of the program, segment, or packet parameters may be 

15 missing. For example, a superframe including these 

parameters may be damaged by transmission anomaly. Or, the 
receiver may power up just after a particular program 
broadcast has started, and will miss parameters broadcast at 
the beginning of the program. Thus the more frequently 

20 these parameters are broadcast, the better the chance that 
at least part of the broadcast program will be properly 
captured, reassembled, and stored. Furthermore, when the 
proper parameters are received, full memory space will be 
allocated for the non- received program part for later 

25 capture, reassembly, and storage during broadcast of a 
second program copy. Therefore the most important 
parameters are identified and then broadcast more often than 
other parameters of lesser importance. 

Table II is a summary showing the required and optional 

3 0 parameters for program capture, reassembly, and storage, and 
for segment playback. Critical parameters, as shown in 
TABLE II, are required in some embodiments to ensure that 
program content is delivered to the user. 
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TABLE II 



PARAMETER 


REQ'D FOR CAPTURE 
AND REASSEMBLY 


REQ'D FOR SEGMENT 
PLAYBACK 


CRITICAL FOR 
PROPER OPERATION 


Program ID 


Yes 




Yes 


Seg. No. 


yes 




Yes 


Pkt. No. 


Yes 




Yes 


Fkts . /Seg . 


Yes 




Yes 


Content Type 




Yea 


Yes 


Edition Time 


Yes 




Yes 


Segs./Pgra. 


Yes 




Yes 


Bytes/Pkt . 




Yes 


Yes 


Bytes/Pgm. 


Yes 




Yes 


Earliest Play Time 






NO 


Expiration Time 






NO 


Bytea/Seg. 




Yes 


No 


Remaining Play Time 






No 


No. of Trans' s . 


Yes 


NO 


Yes 


Pgm. Repetition No. 


Yes 


No 


Yes 



To increase the probability that the receiver receives 
the necessary parameters, some of the parameters described 
5 above are broadcast in the superframe header (e.g., 512, 
FIG. 5), some in the segment header (e.g., 403a, FIG. 4), 
and some in both the superframe and segment headers. As 
shown in TABLE III below, in one embodiment the parameters 
placed in the superframe header are the program identifier, 

10 the segment number, the packet number, the number of packets 
per segment, the content type, the edition time, the 
segments per program, the Bytes per packet and the Bytes per 
program. Thus each one of these parameters is sent once for 
each packet in the program. The parameters in the 

15 superframe header are formatted in fields within table of 
contents 512b (FIG. 5) . The letters A, B, C, and D shown 
next to each parameter name illustrate that the table of 
contents contains one parameter entry for each packet A, B, 
C, and D shown. The parameters placed in the segment header 

20 include several that are in the superframe table of 

contents, plus the earliest play time, the expiration time, 
the Bytes per segment, and the remaining play time. Thus 
each of these parameters is broadcast once for each program 

-19- 



WO 02/11324 



PCT/US01/14823 



segment. These parameters are entered into conventionally 
formatted fields in the segment header. 

Table III summarizes the broadcast placement of 
parameters in one embodiment . Parameters grouped under A 
5 are used during program reassembly. Parameters grouped 
under B are used during playback and are stored with the 
program in memory. Positioning the parameters within the 
table of contents in the superframe header or within the 
segment header is based on the desired frequency of 
10 transmission for each parameter. Other embodiments may have 
particular parameters assigned in various other arrangements 
between the superframe and segment headers. 



TABLE III 







TYPE 


SEGMENT 


SUPERFRAME 


SENT WITH 


SENT WITH 




FIELD 


INFO 


HEADER 


TOC 


BACH PKT. 


EACH SEG. 


A 


Pgm . ID 


Pgm. 


X 


X 


X 


X 




Seg. No. 


Seg. 


X 


X 


X 


X 




Pkt. No. 


Pkt. 




X 


X 






Pkte . /Seg. 


Seg. 




X 


X 




B 


Content Type 


Seg. 


X 


X 


X 


X 




Bd. Time 


Pgm. 


X 


X 


X 


X 




Segs . /Pgm. 


Pgm. 


X 


X 


X 


X 




Bytes/Pkt . 


Pkt. 




X 


X 






Bytes /Pgm. 


Pgm. 


X 


X 


X 


X 




Earliest Play Time 


Pgm. 


X 






X 




Expiration Time 


Pgm. 


X 






X 




Bytee/Seg. 


Seg. 


X 






X 




Remaining Play Time 


Seg. 


X 






X 




No. of Trans' s 


Pgm. 




X 


X 






Pgm. Repetition No. 


Pgm. 




X 


X 





Other receiver operating parameters not discussed above 
may be coded as data contained in one or more packets. 
These parameters are accessed by coded instructions (e.g., 
software, firmware) executed by the microprocessor in the 
20 logic unit. For example, coded parameters may be updates to 
existing quality of service parameters, discussed below. 

FIG. 6 is a memory map showing one embodiment of data 
associated with a particular program stored in the 
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receiver's memory and available for playback. The memory 
allocation shown is illustrative; persons familiar with 
memory management will understand that many storage 
configurations are satisfactory. As depicted, stored 
5 information 600 is all of the stored information necessary 
for outputting a five -segment program to the user. Included 
in information 600 is program information 610, offset index 
620, and segment information 630, 640, 650, 660, and 670 
associated with program segments 1, 2, 3, 4, and 5, 

10 respectively. Program information 610 includes program- 
related parameters, such as the program identifier, edition 
time, segments per byte, Bytes per program, earliest play 
time, and expiration time. Segment information 63 0, 
associated with program segment 1, includes segment 

15 information 632 and segment data 634. Segment information 
632 includes the segment number, content type, Bytes per 
segment, and remaining play time parameters. Segment data 
634 includes the data to be output to the user as audio. 
Segment information 642, 652, 662, and 672, and segment data 

20 644, 654, 664, and 674, each associated with segments 2, 3, 
4, and 5, respectively, contain similar information and data 
as described for segment 1. Offset index 620 includes 
offsets that point to the unique beginning storage location 
for each segment information. Thus, offsets 621, 622, 623, 

25 624, and 625 point to the beginning storage location for 

segments 630, 640, 650, 660, and 670, respectively. These 
offsets may be used, for example, when the user elects to 
skip to a segment subsequent to the one currently in 
playback . 

30 

Quality of Service 

Some embodiments include a packet quality evaluation 
based on conventional digital data transmission error 
checking. Upon receipt, the number of Reed- Solomon failures 
3 5 per packet is determined and a quality code is assigned to 

-21- 



WO 02/11324 PC77US01/14823 

the packet (e.g., 0-5 with 0 best and 5 worst) . In 
addition,, a particular packet may be missing and no quality 
code can be assigned. Within the receiver the digital 
signal processor passes the packet data and the number of 
5 Reed-Solomon failures to the logic unit. Packets with 

acceptable quality codes are stored for use, and those with 
less than acceptable quality codes are either stored or 
discarded. Thus for multiple transmissions of the same 
packet, the packet with the best acceptable quality code is 

10 kept by the receiver. In other embodiments a simple 

pass/fail evaluation is used, and packets with quality codes 
greater than zero (0) are discarded. Logic unit 202 (FIG. 
2) uses these software quality of service features during 
receiver operation. 

15 FIG. 7 is a flow diagram showing packet quality 

evaluation as performed by the receiver's logic unit 202. 
The process is illustrative, and many acceptable variations 
exist. In 702 the packet is captured. In 7 04 the number of 
Reed-Solomon failures is determined and a quality code is 

20 assigned to the received packet data. In 706 the received 
packet's quality code is evaluated against a predetermined 
standard (e.g., only packets with code 0 are acceptable). 
In 7 08 acceptable quality packets are stored for use. If 
the received packet is not of acceptable quality in 706, the 

25 received packet's quality code is compared in 710 with the 
quality code of the same packet received during an earlier 
transmission (if any). If the newly received packet's 
quality is higher, in 712 the newly received packet replaces 
the previously stored packet. If not, the received packet 

30 is discarded in 714. 

FIG. 8 is an illustration of the segment reassembly 
process for a 19-packet segment (54,7 sees of program 
output) . The segment is transmitted twice in this example, 
once as segment 802 during the program's first transmission, 

35 and once as segment 804 during the program's second 
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transmission. Packets 1-19 for each of segments 802 and 804 
have been transmitted in superf rames, although some 
superframes have been corrupted during transmission so that 
some segment packets are unusable (unacceptable quality or 
5 missing) . Acceptable packets (e.g., based on quality 

evaluation discussed above or simple pass/fail) are shown 
(for purposes of the FIG. 8 drawing) with an "X". For 
segment 8 02, packets 8, 11, 12, 14, 18, and 19 are unusable. 
Similarly, for segment 804, packets 2, 9, 10, 12, and 16 are 

10 unusable. By combining usable packets from segments 802 and 
804, segment 806 is constructed with 18 of 19 packets being 
usable. Packet 12 from both transmissions is unusable, but 
the best unusable packet 12 is stored when a packet quality 
evaluation process is used as described above. 

15 Two characteristics regarding the packets in a segment 

are (i) the total number of usable packets within the 
segment, and (ii) the number of consecutive unusable 
packets. In segment 802, for example, 13 of 19 packets are 
usable (68.4 percent). In addition, the largest number of 

20 consecutive unusable packets is 2: packets 11 and 12, and 
packets 18 and 19. Similarly, 14 of 19 packets in segment 
804 are usable (73.7 percent) and the largest number of 
consecutive unusable packets is also 2: packets 9 and 10. 
For the cumulative segment 806, 18 of 19 packets are usable 

25 (94.7 percent) and the largest number of consecutive 
unusable packets is 1: packet 12. 

Compressed program data from an unusable packet is 
unavailable for proper playback to the user, and program 
playback quality suffers. The duration of the unplayable 

30 program (burst) is proportional to the number of unusable 

packets. If the unusable packets are consecutive, playback 
intelligibility suffers in direct proportion to the number 
of consecutive missing packets. If the first five packets 
are missing from a segment, for example, the first 14.4 

35 seconds (5 * 2.88) of the segment are unavailable for 
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playback. But playback quality is also affected by the 
distribution of unusable packets throughout the segment. If 
segment 804 is output to the user, the user misses times 
2.88-5.76 sees, 23.04-28.80 sees, 34.56-37.44 sees, and 
5 43.2-46.08 sees of the program. Segment playback continuity 
is seriously affected in both the consecutive and 
distributed unusable packet situations, and segment playback 
continuity is an important consideration in assessing a 
segment's subjective output quality. 

10 In a similar manner, consecutive or distributed missing 

segments in an entire program affect program quality. In 
addition, in some programs the subjective playback quality 
heavily depends on receiving either the first or last 
segment . First segments may contain an overview of the 

15 entire program that if omitted playback information prevents 
the user from understanding the organization of the 
information that follows. Last segments may contain the 
conclusions or a summary of preceding arguments that if 
omitted will leave the user hanging or confused. 

2 0 Quality of service (QoS) embodiments quantify the 

minimum acceptable level of program quality by requiring 
that a minimum percentage of each segment be present, and 
require that there be no more than a specified number of 
consecutive unusable packets. Quality of service 
25 embodiments also quantify the minimum number of acceptable 
segments in a program, and require that certain segments be 
present in particular programs. Quality of service 
parameters are specified on a program-by-program basis. 

TABLE IV illustrates several possible QoS requirements 

3 0 for various programs (e.g., syndicated radio and other 

programs). The requirements shown are illustrative. 
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TABLE IV 



Program Type 


Segment QoS 
Min % packets Max Burst 


Program QoS 
Min % Sega First/Last Sag 


Caller -Driven 

Tn 1 U- Shows 


85% 


3 


50% 


F/L 


Topic-Driven Talk 
Shows 


85% 


2 


95% 


F/L 


Short Form Neva 


95% 


2 


85% 


F/- 


Long Form News 


65% 


2 | 


95% 


F/L 


One -Segment 


95% 


2 


100% 


F/L 


Bulletins 


100% 


0 


100% 


F/L 


Data 


100% 


0 


100% 


F/L 



Caller-driven radio shows, such as ones currently 
hosted by Laura Schlessinger Ph. D. ( M Dr. Laura"), Dean 
5 Edell, MD, and Tom and Ray Magliozzi ("Car Talk''), typically 
include separate caller interviews that are formatted as 
segments within the programs. There is little , if any, 
cross-reference among interviews and so each interview 
stands on its own. If some interviews (i.e., segments) are 

10 missing, these programs can be presented and will still 

appear coherent to average users. Accordingly, 50 percent 
has been set as the Program QoS minimum percent segments 
requirement. In addition, since each interview is 
relatively long (e.g., an average of four minutes), a 

15 moderate portion (e.g., 15 percent) of the packets in each 
segment and up to 3 consecutive segments (8.6 sees) can be 
missing while maintaining acceptable program quality. 

Topic-driven talk shows typically discuss a single 
topic during the program. Therefore, topic -driven shows can 

2 0 accept only 5 percent missing segments and a burst length of 
only 2 packets (5.8 sees). 

Short format news shows (e.g., half-hourly programs 
originating from the American Broadcasting Company [ABC] or 
National Public Radio [NPR] ) typically have approximately a 

25 five-minute duration. Each story/segment must be of high 
quality and therefore 95 percent of the packets are 
required. In addition, 85 percent of the segments are 
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required for acceptable quality. Current headlines are 
typically broadcast at the start of short format news 
programs and consequently the first segment must be present. 
This program type rarely contains a closing summary and so 
5 the last segment may be missing. 

Long format news shows (e.g., NPR's "All Things 
Considered'') typically contain longer stories/segments than 
short format shows. Long format show QoS parameters are 
similar to those for short format shows, although a larger 

10 number of missing packets is acceptable because the segments 
tend to be longer. Longer segments allow users to better 
establish context even in the presence of more missing 
audio. On the other hand, long format news shows often have 
interrelated stories/segments and therefore a higher 

15 percentage of segments must be present in long format news 
shows than in short format shows . Long format shows also 
may contain conclusions or wrap-up stories so the last 
segment should be present . 

One- segment programs are typically short, single 

20 subject presentations (e.g., "Earth and Sky" produced by 

Byrd and Block Communications, Inc.) . These programs should 
present high output quality on their single segment. 

Bulletins (e.g., short traffic or news bulletins), 
which are often less than one minute in duration, should be 

25 complete. In addition, in some embodiments data such as 
software updates for the receiver, updated quality of 
service parameters, new program guides being presented to 
the user, new system service activation and deactivation 
codes, and critical consumer information (e.g., stock 

30 quotes) must be received error-free to be usable. 

The ability to specify the desired QoS parameters on a 
program-by-program basis allows the service provider to 
define "acceptable" for the users' receivers. The 
subjective quality of "acceptable" may be tailored on a 

3 5 program-by-program basis based on user feedback. If users 
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perceive a particular program's output to be unacceptable, 
the provider can increase one or more QoS parameter 
thresholds until users are satisfied. Alternatively, QoS 
parameters set too high may be lowered with a consequent 
5 decrease in the number of repeat transmissions required for 
a particular program. That is, if acceptable QoS is 
achieved with N-l transmissions instead of N transmissions, 
the Nth transmission may be omitted and the free bandwidth 
may be used to transmit additional programs, either to 

10 increase QoS of other transmitted programs, or to add new 
programs to the service . 

FIG. 9 illustrates an embodiment of received program 
reassembly and evaluation based on QoS parameters as carried 
out, for example, by the receiver's logic unit as software 

15 instructions stored in the memory and executed by the 

microprocessor. As shown, a program having three segments 
902, 904, and 906 is transmitted twice. The first 
transmission is shown as line 910, the second transmission 
as line 912, and the cumulative results of the two 

20 transmissions as line 914 (see the discussion accompanying 
FIGs. 6 and 8 above). Thus as shown, segment 902A is the 
first, 904A the second, and 906A the third of the three 
segments in the program's first transmission. Likewise 
segments 902B, 904B, and 906B are for the program's second 

25 transmission, and segments 902C, 904C, and 906C are for the 
cumulative results. Packets are transmitted in superframes 
with error correction as described herein. 

During the first transmission, all but packets 3, 7, 
and 11 were usable for segment 902A; all but packet 4 for 

3 0 segment 904A; and all but packets 3, 12, 13, and 15 for 
segment 906A. During the second transmission, all but 
packets 4, 5, 8, 9, and 11 were usable for segment 902B; all 
but packet 1 for segment 904B; and all but segments 3, 5, 
15, and 16 for segment 906B. Thus for the cumulative 

35 result, only packet 11 is unusable in segment 902C, all 
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packets are usable in segment 904C, and only packets 3 and 
15 are unusable in segment 906C. 

In this example, the QoS parameters are as follows: 
Minimum packets per segment (QoSl) : 85 percent; Maximum 
5 allowable consecutive unusable packets (QoS2) : 1; Minimum 
segments required per program (QoS3) : 50 percent; First and 
last segments required (QoS4) : yes/yes. The following QoS 
evaluation is illustrative. 

After the first transmission, first segment 902 

10 (segment 902A) failed because only. 8 of 11 packets (73%) 
were received and QoSl requires 85 percent. Segment 902 
passed QoS2 . At this point the program fails QoS3 and QoS4 
because zero of 3 (0%) segments are usable, and because the 
first segment (segment 902) is unusable. Second segment 904 

15 (segment 904A) passed QoSl and QoS2 because 6 of 7 packets 

(86%) were usable and only 1 consecutive packet is unusable. 
The program continues to fail QoS3 because only 1 of 3 
segments (33%) is usable, and to fail QoS4 because the first 
segment is unusable. Third segment 906 (segment 906A) fails 

20 QoSl because only 12 of 16 packets (75%) are usable, and 

fails QoS2 because two consecutive packets (12 and 13) are 
unusable. Thus after the first transmission the program 
fails QoS3 and QoS4 because only one of three segments is 
usable, and because both the first and last segments are 

25 unusable. 

After the second transmission the first, second, and 
third segments are combined with the those from the first 
transmission and the cumulative results are evaluated. As 
shown, first segment 902 (segment 902C) passes QoSl because 

30 10 of 11 packets (91%) are usable. The first segment also 
continues to pass QoS2 . Now, 2 of 3 segments (67%) are 
usable (the second segment from the first transmission and 
the first segment from the cumulative results) and the 
program passes QoS3 . But the third (last) segment is still 

35 unusable, and so the program still fails QoS4 . Second 
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segment 904 (segment 904C) continues to pass QoSl and QoS2, 
but the program still fails QoS4 . Finally, third segment 
906 (segment 906C) passes QoSl because 14 of 16 packets 
(88%) are available, and passes QoS2 because no more than 
5 one consecutive packet is missing. Accordingly, 3 of 3 

segments (100%) are now usable and both the first and last 
segments are usable, so that the program passes QoS3 and 
QoS4. The program is then stored in the receiver's memory 
for output to the user. 

10 FIG. 10 (FIGs. 10A and 10B combined) is a flow diagram 

illustrating an embodiment of a quality of service 
evaluation as carried out, for example, by the receiver's 
logic unit as software instructions stored in the memory and 
executed by the microprocessor. The evaluation is executed 

15 for each new segment that arrives at the receiver. In the 
embodiment shown, evaluation is carried out before data 
decompression, since decompression is part of the output 
playback operation. In 1002 the new segment is captured and 
stored in memory (e.g., a designated "repair" area of memory 

20 208 in FIG. 2) , and the percentage of usable packets in the 
segment is determined in 1004. The first segment quality of 
service test requires that the percentage of usable packets 
in the segment be above a predetermined level (QoSl) . In 
1006 the percentage determined in 1004 is evaluated against 

25 the QoSl threshold. If the segment fails QoSl the method 
moves to 1008. If the segment passes QoSl the maximum 
number of consecutive unusable packets is determined in 
1010. The second segment quality of service test requires 
that the number of consecutive unusable packets in the 

30 segment be less than a predetermined threshold (QoS2) . If 

in 1012 the segment fails QoS2 the evaluation moves to 1008, 
but if the segment passes QoS2 the evaluation moves to 1014, 
indicating that the segment has passed both quality of 
service tests. The program quality is then evaluated. 
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In 1016 the percent of usable segments (stored in 
memory) is determined. The first program quality of service 
test requires that the percentage of usable segments in the 
program be above a predetermined level (QoS3) . If the 
5 program to which the new segment belongs fails QoS3 the 
evaluation moves to 1020. At this point in 1022 it is 
determined if more segments are expected to be received. If 
so, the evaluation returns to 1002 and awaits another 
segment for this program. If no additional segments are 

10 anticipated, the program is determined to be unusable in 
1024. If the new segment passes QoS3 in 1018, it is then 
determined if the first and/or last program segments are 
usable. The second program quality of service test requires 
that the first and/or last segments in a program be usable 

15 if so specified (QoS4) . If the first and/or last segments 
are not usable as required, the program fails QoS4 in 1026 
and the evaluation moves to 1020. If the program passes 
both QoS3 and QoS4 the program is determined to be usable in 
1028. 

20 FIG. 11 is a flow diagram of a second embodiment of a 

quality of service evaluation as carried out, for example, 
by the receiver's logic unit as software instructions stored 
in the memory and executed by the microprocessor. As 
described above, packets may be continually arriving at the 

25 receiver. When the last packet in a segment is captured, 
the segment is then stored. If multiple transmissions of 
the same program are made, an earlier version of a 
particular newly arrived segment will have been previously 
stored. In 1102 the method waits for the next packet to 

30 arrive at the receiver. In 1104 the new packet is captured 
and in 1106 it is determined if the packet is associated 
with a new segment (i.e., the first packet associated with a 
following segment) . If not, the segment captured during a 
previous transmission of the program (if any) is tested in 

35 1108 as described in relation to FIG. 11 below and the 
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evaluation moves to 1110. In 1110 the evaluation determines 
if packets are still being captured for the program 
associated with this new packet, as directed by 1108. If in 
1106 the new packet is part of a new segment, the evaluation 
5 moves directly to 1110. 

If in 1110 packet capture for this program has stopped, 
the evaluation returns to 1102. Otherwise, the evaluation 
moves to 1112 and saves the new packet if it is better 
quality than the corresponding packet saved in the 

10 previously stored version of the segment. In 1114 the 
evaluation determines if the packet has completed the 
segment and, if not, it returns to 1102. If the new segment 
is complete it is evaluated using the 1108 method. When 
evaluation is complete, in 1116 it determines if more 

15 packets are expected and if so, returns to 1102. Otherwise 
this embodiment ends . 

FIG. 12 is a flow diagram of the segment evaluation 
method referred to in 1108 of FIG. 11. Quality of service 
tests QoSl, QoS2, QoS3, and QoS4 are as described in 

20 relation to FIG. 10. The segment is evaluated against QoSl 
and QoS2 as shown in 1202 and 1204, respectively. If the 
segment passes both tests it is marked in 1206 as passed. 
Otherwise 1108 ends. If in 1208 the segment is part of the 
first transmission of the program 1008 also ends. But if 

25 1208 determines that the last packet of the last segment of 
the first transmission has been received, or if the segment 
is from a subsequent program transmission, the program is 
evaluated against QoS3 and QoS4 as shown in 1210 and 1212, 
respectively. Programs successfully passing QoS3 and QoS4 

3 0 are marked in 1214 as passing and capture of the particular 
program ends. In this embodiment capture ends when 
acceptable QoS standards have been met so as to make the 
program available for playback. Persons skilled in the art 
will appreciate, however, that in other embodiments the 

3 5 programs may be restricted from output until all 
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transmission have been received, thus potentially providing 
a quality of service in excess of the acceptable QoS 
standards . 

Note that coding the software or firmware to carry out 
.5 the processes of FIGs. 7, 10, 11, and 12 would be routine in 
light of this disclosure, using a programming language 
compatible with the microprocessor in logic unit 202. 
Similarly, designing an application-specific circuit using a 
standard hardware design language would also be routine. 

10 These embodiments offer several advantages. FirBt, the 

service provider may specify one or more unique quality of 
service standards for each program delivered. Second, 
subjective concepts of quality are translated into objective 
measurements of both the entire program and portions of the 

15 program. Third, when a particular program is received more 
than once, the receiver may use the quality of service 
parameters during program reassembly to determine when the 
program and its portions have satisfied quality of service 
parameters. Fourth, the quality of service parameters may 

20 be made more stringent at the service provider's discretion. 
Fifth, the quality of service parameters may be made less 
stringent, enabling the service provider to decrease the 
number of repeat transmissions for selected programs and 
consequently allowing the total number of programs, or the 

25 quality of other programs, to be increased. 

Persons skilled in communications will realize that the 
invention is not limited to the various embodiments 
described. Quality of service parameters may be applied to 
various metrics that quantify the subjective program 

3 0 delivery quality. Such metrics include the clustering of 
damaged packets (e.g. , density of unusable or missing 
packets is too high in a given program, or within a 
predetermined number of consecutive packets) , the clustering 
of damaged segments (e.g., density of unusable or missing 

35 segments is too high in a given program, or within a 
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predetermined number of program segments) , specifying 
specific packets that must be received, specifying specific 
segments (other than first or last) that must be received, 
and transmitting the quality of service parameters with the 
5 program itself or within the superframe table of contents. 

Consumer Rating and Behavior Evaluation System 

It is desirable for the local storage and playback 
broadcast system service provider to monitor signal and 

10 program quality reception at the receivers and also to 
monitor the users' content consumption patterns. 

Programs broadcast to the user's portable receiver are 
broadcast on the "forward channel." Information taken from 
the user's receiver and directed back to the service 

15 provider is routed via the "back channel." Information to 
be transferred from the receiver to the service provider 
includes "back channel events" that are grouped into five 
major categories. Each back channel event is stored in a 
back channel log file that in some embodiments includes a 

2 0 date/time stamp that is used to determine the time of the 

event or the duration between events. The back channel log 
is stored in memory 2 08 (FIG. 2) . In some embodiments the 
back channel events are transferred from memory 208 to 
removable data storage medium 234 ("back channel card" ) 

25 which functions as a vehicle for information transfer back 
to the service provider. In other embodiments the back 
channel events are transferred to the service center via a 
conventional communications link coupled to terminal 235. 
Capture events describe the quality of segments and 

30 programs when they are stored by logic unit 202 in memory 
210. Capture events show how well each segment and each 
program are received. The combined capture events from many 
receivers provide the service provider with an indication 
about how well all system receivers are receiving broadcast 

35 programs. Capture events include QoS events, which are 
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based on QoS determinations described above, and also 
include summary segment and program statistics events, such 
as the number of programs that passed or failed in a given 
time period (e.g., per hour or per month) . Summary segment 
5 and program statistics measure the distribution and total of 
individual segment and program quality events. In some 
embodiments the summary segment and program statistics 
events are derived from QoS events. Saving the statistics 
rather than the raw events at the receiver saves storage 

10 space in memory 208- In some instances, information 

required to record capture events is taken from signals 
occurring on line 2 03, in memory 210, or on line 225. 

Storage management events occur as logic unit 2 02 
reassembles, stores, copies, and deletes programs in memory 

15 210. Storage management events are recorded whenever a 
program is saved, copied, or deleted. A "save" event is 
recorded when, as described above, audio programs are saved 
in memory 210 when first captured for playback. A "copy" 
event is recorded when the user elects to save a particular 

20 program by copying the program into the "saved programs" 
memory area. A "delete" event occurs when logic unit 202 
deletes a previously stored program from memory 210 in order 
to make room for storing a new program. Thus storage 
management events indicate to the service provider the 

25 programs that have been captured by the receivers, how long 
the captured programs were available for playback, and if 
users saved the programs in the "saved programs" memory 
area. In some instances, information required to record 
storage management events is also taken from signals 

30 occurring along line 203, within memory 210, or on line 225. 
Playback events include user inputs (e.g., button 
presses and switch changes) , actual user playback program 
selections, and changes to the receiver's program capture 
list. Each user input made on input unit 224, for example 

35 pushing the "next" or "scan forward" buttons as described 
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above, is recorded. Playback events indicate to the service 
provider the programs that were selected for playback, the 
ones actually played (including edition number) , the times 
they were played, and receiver options that were changed. 
5 Such receiver options include the number of programs stored 
in the capture list, or a selection between immediate or 
deferred playback of bulletins. In some instances, 
information regarding playback events may be taken from 
signals occurring along line 225. 

10 Control events occur whenever the receiver is tuned to 

a new FM frequency on the FM frequency list, described 
above, or when power source 230 changes. If signal 114 does 
not contain the desired subcarrier signal, DSP 212 reports 
this discrepancy to logic unit 202 that, in turn, directs 

15 via line 217 receiver unit 218 to tune to the next frequency 
in the FM frequency list and logs a "retune" control event. 
Logic unit 202 also records a * change of receiver power 
source" control event when power system 228 detects a change 
in power source. The control events allow the service 

20 provider to see how often retuning was required (an indirect 
indication of signal quality) and the likelihood of users 
using particular power sources (an indirect indication of 
where the users are using their receivers) . In some 
instances control event data is taken from lines 217 and 

25 229. 

Signal quality events include statistics, stored for 
example in DSP memory 214, regarding the errors that the 
digital signal processor encounters as it receives programs. 
Signal quality events provide the service provider with an 

30 indication of how well the broadcast encoded signal is being 
received. Channel error rate is an indication of overall 
channel (e.g., FM broadcast frequency) quality, so that the 
higher the error rate, the higher the likelihood of capture 
errors. Channel errors are measured by comparing the 

3 5 received symbols (a symbol represents two bits) prior to 
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Viterbi decoding to the re -encoded output bits of the 
Yiterbi decoder. The synchronization error rate is a 
measurement of synchronization word errors. DSP 212 
identifies the number of bits within each synchronization 
5 word that have been damaged in transmission because the 

words are placed at regular intervals and the bit pattern is 
known. The synchronization error provides an estimate of 
the channel error rate . The sync bits represent only about 
two percent of the bits in a superframe, whereas the channel 

10 error rate includes the errors with respect to the remaining 
ninety-eight percent of the superframe bits. The Reed- 
Solomon error rate is the number of Reed-Solomon errors per 
Reed-Solomon data block (e.g., 255 Bytes as described 
above) . The Reed- Solomon failure rate is the number of 

15 Reed-Solomon failures (e.g., more than 16 Byte errors in a 
Reed- Solomon block) per superframe. 

In addition to the five categories of events listed 
above, n meta events" are also defined. Meta events include 
the insertion of the removable data storage medium into the 

20 recorder (detected by a unique file stored on the medium) . 
When the card is inserted, logic unit 202 recognizes the 
back channel card, information identifying the specific 
receiver is recorded on the card, and back channel data is 
automatically copied to the card from memory 210. Thus the 

25 user's previously gathered demographic information is 
correlated with recorded back channel events . This 
correlation provides valuable advertising information 
regarding the listening habits of specific users. Meta 
events also include recording of any transfer of the 

3 0 receiver to a new geographic area. Such transfer is 

detected using the market code in fields 512a of FIG. 5. 
Meta events further include enabling or disabling monitoring 
of ^certain back channel events. For example, if the 
receiver's power switch is turned off, signal quality, 

35 storage management, and capture events no longer need to be 
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monitored. Thus meta events from multiple receivers 
indicate to the service provider how the receivers have 
moved among two or more service areas. 

In one embodiment, the service provider mails 
5 SMARTMEDIA® cards via the United States Postal Service or 
similar delivery service to a select group of users (back 
channel participants) . To establish valid back channel 
statistics, at least two percent of the system users should 
be randomly chosen to be back channel participants. 

10 FIG. 13 is a diagrammatic view illustrating an 

embodiment of the consumer rating and evaluation system. As 
described above, program content and other parameters are 
accessed from database 104 and the accessed information is 
transmitted using transmitter 106 via signal 108 to 

15 audio/video-on-demand receiver 116. Receiver 116 captures 

the broadcast information on the receiver's capture list and 
stores the captured information in memory. In addition, 
service provider 1302 delivers one or more media cards 1304 
to each unique user who is a back channel participant. When 

20 each participant receives the back channel card, he or she 
inserts the card into recorder 23 2 in the receiver. The 
receiver detects that the card is a back channel card by 
identifying the existence of a unique file or identifier 
stored on card 13 04 and consequently copies the stored 

25 events in the back channel events log file to the card. The 
receiver provides an indication (e.g., indication on the 
visual display) when the copying is complete . The user 
subsequently returns recorded cards 1306 to the service 
provider who then inserts the cards into card reader 1308. 

30 In one embodiment, reader 1308 is configured with eight 

conventional reading units that allow data to be read from 
SMARTMEDIA® cards 1306. In this embodiment the reading 
units are the same as recorder unit 232, although other 
reading units can be used in other embodiments. Data from 

35 reader 13 08 is routed through conventional computer 1310 and 
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is stored in conventional database 1312 that is maintained 
on a computer (e.g., computer 1310 or a separate 
conventional computer) . The service provider may then 
access the back channel events stored in database 1312 
5 using, for example, a structured query language (SQL) 

database program such as MICROSOFT ACCESS® or ORACLE SQL®. 
The back channel information is then incorporated with other 
known information (stored for example in database 1312) 
about the users to analyze user behavior across specific 

10 sub-populations (e.g., to determine how often women users 
demand and play back sports programs, or to determine if a 
particular program is the highest rated program in a 
specific sub -population) . Once analysis is complete , 
computer 1310 outputs report 1314 to the service provider. 

15 FIG. 14 is a diagrammatic view of one embodiment of 

card reader 1308. In the embodiment shown in FIG. 14, 
reader 1308 is a modified Command Audio Corporation CA-1000 
board typically used in receiver 116 (FIG. 1) that includes 
eight reading units that are the same type as recording unit 

20 232 (FIG. 2) . Logic unit 1402 is electrically coupled to 
conventional NOR flash memory 1404, conventional RAM 1406, 
and conventional NAND flash memory 1408. The memories 1404, 
1406, 1408 together are included in memory 1410. Logic unit 
1402 is electrically coupled to eight reading units 1432a- 

25 1432h via line 1433. Terminal 1435 (e.g., conventional 
eight -channel serial cable connector) is coupled to line 
1433 so that information stored on media cards inserted into 
reading units 1432a-1432h can be accessed by an outside 
computer (e.g., computer 1310). Since in this embodiment a 

30 modified Command Audio Corporation receiver card is used, 
elements 1402, 1403, 1404, 1406, 1408, 1410, 1432a, 1433, 
and 1435 are analogous to elements 202, 203, 204, 206, 208, 
210, 232, 233, and 235, respectively, as shown in FIG. 2. 
Specific embodiments have been disclosed above. 

35 Persons skilled in the art will understand, however, that 
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many variations of these specific embodiments exist. 
Therefore, the invention is limited only by the scope of the 
following claims. 
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CLAIMS 
We claim: 

1. A receiver comprising: 

a logic unit; 
5 a memory coupled to the logic unit; 

a signal processor coupled to the logic unit; and 

a recording unit coupled to the logic unit, 
wherein the recording unit is configured to receive and 
record information onto a removable data storage 
10 medium; 

wherein the signal processor is configured to 
extract audio program information from a broadcast 
wireless signal for storage by the logic unit in the 
memory; 

15 wherein the logic unit is configured to monitor 

operation information relating to operation of the 
receiver; and 

wherein the logic unit is further configured to 
store the operation information in the memory. 

20 

2. The receiver of claim 1, wherein the operation 
information pertains to capture of the program information 
from the signal . 



25 3. The receiver of claim 1, wherein the operation 

information pertains to storage management of the program 
information in the memory. 



4. The receiver of claim 1, wherein the operation 
30 information pertains to use of the stored program 

information by a user of the receiver. 

5. The receiver of claim 1, wherein the operation 
information pertains to playback of the stored program 
information by the receiver. 
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6. The receiver of claim 1, wherein the operation 
information pertains to control of the receiver's tuning 
frequency or power source. 

5 7. The receiver of claim 1, wherein the operation 

information pertains to a quality of the signal as received 
by the receiver. 

8. The receiver of claim 1, wherein the operation 
10 information pertains to an event chosen from the group 

consisting of insertion of the removable storage medium into 
the recording unit, transfer of the receiver from a first to 
a second geographic area, enabling the monitoring of first 
selected events, and disabling the monitoring of second 
15 selected events. 

9. A method of obtaining information pertaining to use 
of a broadcast program service, comprising the acts of: 

providing a receiver that includes a memory and a 
2 0 recording unit, wherein the receiver is configured to 

extract program information from a wireless broadcast 
signal and to store the extracted program information 
in the memory; 

recording in the memory operation information 
25 associated with operation of the receiver; 

providing a removable storage medium; 
transferring the stored operation information from 
the memory to the removable storage medium; and 

obtaining the removable storage medium containing 
30 the operation information. 

10. The method of claim 3, wherein the operation 
information pertains to capture of the program information 
from the signal. 



35 
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11. The method of claim 9, wherein the operation 
information pertains to storage management of the program 
information in the memory. 

5 12. The method of claim 9, wherein the operation 

information pertains to use of the stored program 
information by a user of the receiver. 

13. The method of claim 9, wherein the operation 
10 information pertains to playback of the stored program 

information by the receiver. 

14. The method of claim 9, wherein the operation 
information pertains to control of the receiver's tuning 

15 frequency or power source. 

15. The method of claim 9, wherein the operation 
information pertains to a quality of the signal as received 
by the receiver. 

20 

16. The method of claim 9, wherein the operation 
information pertains to an event chosen from the group 
consisting of insertion of the removable storage medium into 
the recording unit, transfer of the receiver from a first to 

25 a second geographic area, enabling the monitoring of first 
selected events, and disabling the monitoring of second 
selected events. 
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